Erlang Killer Apps

В Эрланг среде принятно считать, что RabbitMQ и Riak, или по крайней мере
riak_core — являются киллер приложениями Erlang. Я сам помню на начале своей
карьеры тоже поставил на эти продукты и еще на Nitrogen. С нитрогеном я
разобрался быстро (он уже история — все используют N2O уже давно). Настала
очередь Riak или RabbitMQ, не знал за что взяться. Взялся сразу за
распределенную базу, но так быстро на распределенные алгоритмы не наскочишь, а
тестами покрывать распределенные системы — это не в этой жизни, может в
следующей, если плохо себя вести буду. Вообщем исследование Chain Replication
завело меня в тупик зависимых типов и я начал пить™.

Расскажу какие мысли у меня были во-первых по Riak. Riak после всего что я
видел до него поверг меня в шок стоимостью обслуживания продакшина. Я с
легкостью строил кластера пока не понял что они мне совершенно не нужны. Из
riak нужно реально только riak_kv, riak_core и riak_pipe. Причем я даже собирал
Riak без bitcask полностью (он вшитый в ядро) и многие другие штуки делал типа
порт Riak под Windows 8. Собственно KVS появился как штука чтобы не ебаться с
голым riak. В Riak вы храните бинари, а в KVS типы-рекорды описаные в схемах.
Это потом в KVS появились бекенды.

Паралельно у меня был кластер из трех RabbitMQ. Тогда уже я понял что
производительность RabbitMQ высокая только если они работают в шардах (не
кластер, потому что интерконнет хуйовый у эрланга). Т.е. реально RabbitMQ
используют все просто как ETS с красивым дашбордом для админов. Забейте хуй на
RabbitMQ, эта штука покрыта кольцами как и Riak. Счас есть гораздо емкостные MQ
типа emqtt.io (gproc в качестве деливери, mnesia — для дюрабилити), тоже причем
с красивыми дашбордами. У меня кстати есть заказ от Остинелли на порт emqtt.io
с gproc на syn.

Но я не об этом.

Спросите себя почему MQ и KV сервера в вашем окружении (а они у вас все равно
есть, какое бы вы приложение не писали) находятся в разных приложениях. Ведь в
вашем приложении MQ обслуживает клиентов, и KV обслуживает клиентов. Поэтому
тут работатет data locality, а значит можно посадить это на одни и теже воркеры
vnode. Но почему у всех ПОГОЛОВНО MQ и KV сервера — это разные продукты? Почему
так? Ответа не нашел. Продуктов нет (разве что redis). Поэтому я подумал
написать (еще два года назад) MQ + KV сервер работающий на одном ядре. И ядро
это KVS.

KVS отвечает за durability, MQ должен хранить сабскрипшин меш своих подписок а
также все сообщения (если очередь скажем персистента или нужны ACK или нужна
транзакционность). Вполне очевидно что это можно хранить в том же KVS. Уверен
что все люди которые используют RabbitMQ (илии другие MQ продукты) дублируют и
синхронизируют свой сабскрипшин меш приложения и состояние подписок в mnesia
таблицах RabbitMQ. Нахуя? Незнаю, в моем MQ такого дублирования не будет.

Какие я могу обеспечить показатели MQ сервера на KVS:

1) ну я могу выжать из мнезии 40K RPS на данных которые помещаются в RAM, и 20K
RPS на данных которые не ограничиваются ничем. async_dirty естественно.

2) Data Locality. И серверы очередей и серверы данных будут обслуживать на
одних и тех же vnode (по 64 или 128 на ноду), т.е. вычислятся хешом по
идентификатору пользователя, а значит исчезает необходимость в синхронизации,
так как все сообщения от MQ и KV протокола будут помещены в одну и туже очередь
пользователя (линеаризация во имя консистентности).

3) Благодаря KVS, и MQ сервер и KV сервер будут поддерживать все бекенды
которые поддерживает KVS: mongoDB, SQL, Riak, mnesia, redis.

4) доступ к очередям можно получать напрямую читая их из базы, если нужно. Еще
был план написать универсальный REST эндпойнт к KVS как в Riak и CouchDB, и
чтобы этот же эндпойнт был API для MQ сервера.

Ну и этот конструктор не имеет ограничений. На KVS можно лепить уже более
сложные API и системы. Пример CR хоть и заезженный, но рабочий.

Вообщем надо соединять MQ и KV сервера, мое мнение, а вы делайте как хотите :-)